NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c/296

Internet Message Format | 1996-08-06 | 5.9 KB

Path: newshost.lanl.gov!tanmoy
From: [e-mail] (Tanmoy Bhattacharya)
Newsgroups: comp.lang.c,comp.lang.c++,gnu.gcc.help,gnu.g++.help,comp.os.msdos.djgpp,comp.std.c
Subject: Re: float != float and floats as return types
Date: 03 Feb 1996 17:56:44 GMT
Organization: Los Alamos National Laboratory
Message-ID: <[e-mail]>
References: <4ej9lb$[e-mail]> <4elnjj$[e-mail]>
    <4eqc7l$[e-mail]> <4eqtu3$[e-mail]>
    <[e-mail]> <4ettr4$[e-mail]>
NNTP-Posting-Host: qcd.lanl.gov
Mime-Version: 1.0
Content-Type: text
In-reply-to: [e-mail]'s message of 2 Feb 1996 12:57:08 -0800


Note that I have added comp.std.c to the list of newsgroups.

In article <4ettr4$[e-mail]> [e-mail] (Paul
Eggert) writes:
   [e-mail] (Tanmoy Bhattacharya) writes:

   > I do not agree with this interpretation, as the footnote (technically,
   > not part of the standard) clarifies: an assignment and cast both must
   > truncate the result to the required precision.

   Sorry, that footnote doesn't clarify matters.  All the footnote says
   is that the required conversions must be performed.  In the example
   we're talking about, there's no conversion to be performed, since
   both sides of the assignment have `float' type.

There are two issues to be considered when interpreting the
standard. In comp.std.c, the only concern is what the standard says
and whether this is reasonable and consistent. In other discussions,
including discussions of concrete implementations, I would guess what
is important is also what the committee was trying to say, even if
they did muddle up the issue. In this particular instance, the
footnote would be completely redundant if the committee did not want
the extra precision to be truncated. (At least, I cannot see any
reason to put in the footnote otherwise.)

   Furthermore, even if there is a conversion, I don't see where the standard
   requires that excess precision be discarded.  All the standard requires is
   that the result be ``represented exactly''; it doesn't say what it means
   by this, and an implementation that keeps excess precision is certainly
   representing _its_ result exactly.  The standard explicitly licenses
   excess precision, and never explicitly (or implicitly, as far as I can
   see) requires excess precision to be discarded.

   Also please see ANSI C 3.3.4, which says ``A cast that specifies no
   conversion has no effect on the type or value of the expression'';
   this means that an implementation with extra precision is not allowed
   to discard it because of a cast of float to float.  It is natural to
   assume that assignment of float to float can behave similarly to a cast.

As you explicitly state, this is a conversion from float to float, so
no conversion ought to take place according to the section
quoted. This, I believe, needs to be corrected: I guess the
possibility of extra precision was not thought of in this section. On
the other hand, a conversion from double to float explicitly says
(6.2.1.4) that the result is representable as a float exactly ... and
quantities with extra precision is not. Hence, (float)(1.0/3.0) must
be a value representable in a float (and I guess, representable is
according to the guidelines in <float.h>), and, practically, it makes
little sense to have (float)(x/y) have more precision if x and y are
floats than if they were double or long double!

Furthermore, in an expression like (a=b*c)+d, the semantics is
explicitly specified in the standard. (b*c) may be evaluated in
extended precision, the result stored into a, the new stored value of
a is then to be added to d. As one is assuming that the stored value
of a cannot hold the extra precision, the quantity added to d must be
the truncated value. Hence, b*c+d can be different from (a=b*c)+d.

It would not be practically useful to have (a=b*c)+d truncate whereas
(float)(b*c) + d not truncate. I think, that unless the committee
speaks otherwise, one can assume that cast and assignments indeed are
intended to truncate.

   I realize that the standard is muddled in this area -- for example, the
   Rationale contradicts it, and I've been told that the C Standard committee
   may amend 3.3.4 because of the problem with floating point casts
   (surely an implementation should be allowed to discard excess precision
   whenever it wants to).

   That being the case, I think it wise for users not to rely on the fine
   points here, and my advice to the GCC implementers is to hold off on
   changing GCC's behavior until the C Standard committee acts.

I, on the other hand, think that the current standard  ought to be
interpreted to mean that truncation is needed. Claiming that it is not
needed is relying on the fine points. That is purely a personal
opinion.

The counter opinion that not truncating should be permitted on grounds
of efficiency, I believe is a red herring. The C standard has already
been written such that many useful optimizations cannot usually be
performed by the compiler on floating expressions: a compiler is not
free to rewrite a+b+c as a+(b+c) anyway (if a conforming program can
detect the change, that is). For numerical work, one needs a flag
which specifies standard-violating optimizations: or user coding of
the exact transformations needed: with common subexpression
recognition. Not truncating in the standard conforming mode is
therefore neither useful nor necesary.

Cheers
Tanmoy
--
[e-mail](128.165.23.46) DECNET: BETA::"[e-mail]"(1.218=1242)
Tanmoy Bhattacharya O:T-8(MS B285)LANL,NM87545 H:#9,3000,Trinity Drive,NM87544
Others see <gopher://yaleinfo.yale.edu:7700/00/Internet-People/internet-mail>,
<http://alpha.acast.nova.edu/cgi-bin/inmgq.pl>or<ftp://csd4.csd.uwm.edu/pub/
internetwork-mail-guide>. -- <http://nqcd.lanl.gov/people/tanmoy/tanmoy.html>
fax: [phone]   voice: 1 [phone]    [ Home: 1 [phone] ]